6 Visa Contact VIS and EMV Settings

This section describes the Visa Integrated Specifications (VIS)Closed A set of standards covering aspects of transaction processing such as security protocols, data formats, and communication methods between payment devices and networks. settings relevant to Thredd for the Visa Contact application.

The Tag values are as mentioned in the EMV VIS table A-1 “Data Element Descriptions”.

This table only includes the parameter/tag settings that are relevant to Thredd.

Tag & Name

Byte / Bit (s)

Description

Thredd comment

Application Default Action

‘9F52’

[VIS]

Byte 1

bit 7

b1 = If Issuer Authentication performed and failed, decline transaction.

You can set this to ANY, however you should consider the following:

Visa currently recommend that this SHOULD be set to b0, in case an acquirer error causes the ARPC to be altered when sent to the card. (However, this makes it difficult to verify the ARPC is correct.)

HOWEVER, there are advantages to setting this to b1, so that an invalid ARPC will decline the transaction.

This ensures that ARPC is working, and also prevents fake online responses (as Thredd and Visa will always send a valid ARPC.)

So Thredd recommend you consider setting this to b1.

 

Byte 1

bit 6

b1 = If Issuer Authentication is mandatory and no ARPC received, decline transaction.

We recommend that this SHOULD be set to b1, for the same reasons as above.

 

Byte 2

bit 8

b1 = If PIN Try limit exceeded on current transaction, block application.

You can set this to ANY.

But if setting to b1, understand that a new card must be issued if the offline PIN is blocked.

 

Byte 2

bit 7

b1 = If PIN Try limit exceeded on previous transaction, decline transaction

You can set this to ANY.

But if setting to b1, this might prevent the offline PIN being reset by Thredd if the offline PIN is blocked on the chip.

 

Byte 2

bit 4

b1 = If Issuer Script failed on a previous transaction, transmit transaction online

You can set this to ANY.

However, having set to b1 will assist in diagnosing any Issuer Script failures.

 

Byte 2

bit 3

b1 = If PIN Try Limit exceeded on previous transaction, decline and block application

You can set this to ANY.

But if setting to b1, if the offline PIN is blocked, a new card must be issued.

 

Byte 3

bit 3

b1 = Use Issuer Script MAC Chaining Option

This MUST be set to b0.

Thredd does support Issuer Script MAC Chaining

 

Byte 3

bit 2

b1 = Issuer Script Command Counter is cyclic.

Thredd recommend it SHOULD be set to b0, to retain backwards compatibility with the standard way the Visa Card script results work, so that anyone manually looking at the values is not confused.

However, there is no automated Thredd process for checking the “script failed” or script command counter, so you can set this to ANY.

 

Byte 4

bit 5

b1 = Padding method ‘80’ supported for IDD MACing

You can set this to ANY.

However, note that Thredd does not currently support validation of the IDD MAC.

 

Byte 5

bit 1

b1 = Secure Messaging uses EMV Session-key based derivation

You can set this to ANY.

(This bit will be sent in the CVR and Thredd will inspect it to determine the Secure Messaging key derivation method.)

Application Interchange Profile

Tag ‘82’

[EMV]

Byte 1

bit 1

b1 = CDA is supported

You can set this to ANY.

Note however that Thredd recommends it SHOULD be set to b1 if the card supports this, in order to avoid man-in-the-middle wedge attacks on chip transactions.

CVM List

Tag ‘8E’

 

List of Cardholder Verification Methods

You can set this to ANY.

 

However, if Issuer Action Code – Denial (Tag ‘9F0E’) byte 3 bit 8 (cardholder verification) is ‘1’, then it is very important that if Offline PIN CV fails, the CVM list will try online PIN.

Cryptogram Version Number

Part of ‘9F10’

[VIS]

Byte 1

Upper nibble: ‘9F10’ format (including Secure messaging algorithm in VIS 1.6.1)

Lower nibble: Application Cryptogram algorithm

This MUST be set to one of the following:

Hex value

Decimal value

‘0A’

10

‘12’

18

‘22’

34

Thredd also supports Cryptogram version hex ’11’ (decimal 17), but this is only for contactless only.

See Appendix 1: Mastercard Cryptogram Version Number Values.

Any other cryptogram version number will result in a decline.

Issuer Action Code – Denial

‘9F0E’

[EMV]

Bytes 1 to 5

Compared against the TVR by the terminal – any bits in common will result in transaction being declined offline.

You can set this to ANY.

But note that they should set this with care, since if a test would always be TRUE for all transactions, the card is effectively useless, and a new one may need to be issued.

Issuer Action Code – Denial

‘9F0E’

[EMV]

Byte 3

bit 8

Cardholder verification failed

If set to ‘1’ (decline offline if cardholder verification failed), then they should ensure that this will not prevent the card coming online to receive a new offline PIN.

If this set to ‘1’, then the CVM list (tag ‘8E’) must be setup to ensure there that a blocked offline PIN does not permanently prevent the card going online to retrieve a new offline PIN. (See CVM list Tag ‘8E’ above.)

Issuer Action Code – Online

‘9F0F’

[EMV]

Bytes 1 to 5

Compared against the TVR by the terminal – any bits in common will result in transaction being sent online.

You can set this to ANY.

But note that care should be taken when deciding how to set this.

Issuer Action Code – Default

‘9F0D’

[EMV]

Bytes 1 to 5

Compared against the TVR by the terminal – any bits in common will result in transaction being declined offline if: online was requested but not possible.

You can set this to ANY.

But note that care should be taken when deciding how to set this.

Issuer Application Data

Tag ‘9F10’

[VIS]

[EMV]

All bytes

as defined in [VIS] to be sent to the issuer online.

 

First byte MUST be ‘06’ or ‘1F’.

Any other value will result in transactions being declined.

See Appendix 1: Mastercard Cryptogram Version Number Values.

See also “Derivation Key Index” and “Cryptogram Version Number” above.

Issuer Authentication Data

Tag ‘91’

[VIS]

[EMV]

All bytes

Data from the Issuer (Thredd here) to be sent back to the card in an online transaction response.

Note that Thredd does not currently support sending “proprietary authentication data”.

 

Log Entry

Tag ‘9F4D’

[EMV]

Byte 2

Maximum number of records in the transaction log file

You can set this to ANY.

The transaction log can be useful:

  • for cardholders (if offline transactions are supported, and you provide a way of reading the transaction log available to the cardholder)

  • for the Issuer or Program Manager if you physically possess the card, and have a reader, to diagnose what happened on previous transactions.

Profile Control “x”

Tags ‘DF1x’ in Template ‘BF59’

Various

Configures the application data and behaviour to be used for transactions conducted using the profile.

See comments for “Application Default Action” for bits which have the same meaning.